System and method for using a symbol as instruction for a target system to request identity information and authentication from a mobile identity

ABSTRACT

Some implementations may provide a method to have a user authenticated at a point of service. The method includes: accessing, by a target system, a multi-dimensional symbol rendered on a display of a mobile computing device of the user, the multi-dimensional symbol encoding endpoints and actions for the target system to perform in order to request and authenticate an identity of a user; decoding data in the multi-dimensional symbol to retrieve an identity token plus information about the authentication actions and the user&#39;s identity system; requesting the corresponding authentication actions of the user&#39;s identity system to include specific authentication measures for the user to perform as well as data for the user to release; and performing the authentication actions as requested and encoded in the multi-dimensional symbol such that the physical identity of the user of the mobile computing device is verified and the user consents to release the requested identity information at the point of service.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/782,362, filed Oct. 12, 2017, now U.S. Pat. No. 10,200,863, which isa continuation of U.S. patent application Ser. No. 15/280,211, filedSep. 29, 2016, now U.S. Pat. No. 9,801,064, which claims the benefit ofU.S. provisional patent application Ser. No. 62/234,332 filed Sep. 29,2015 and U.S. provisional patent application Ser. No. 62/273,813 filedDec. 31, 2015, the contents of both are incorporated by reference intheir entirety for all purposes.

TECHNICAL FIELD

This document generally relates to identity management.

BACKGROUND

Identity management has become a perennial concern in the age of mobilecomputing when a consumer user may carry a mobile computing devicethrough which a variety of on-line electronic transactions may beconducted. For example, transactions between a consumer and a providermay be subject to risks of identity theft, identity fraud, spoofing,phishing, etc., all of which may potentially hinder the flow ofcommerce. Consumer identities are distributed across various “accounts”that are difficult to manage and not always accessible at thepoint-of-sale or while mobile.

SUMMARY

Some implementations provide a method to have a user authenticated at apoint of service and to release identity information, the methodincluding: accessing, by a target system, a multi-dimensional symbolrendered on a display of a mobile computing device of the user, themulti-dimensional symbol encoding endpoints and actions for the targetsystem to perform in order to request and authenticate an identity of auser; decoding data in the multi-dimensional symbol to retrieve anidentity token plus information about the authentication actions and theuser's identity system; requesting the corresponding authenticationactions of the user's identity system to include specific authenticationmeasures for the user to perform as well as data for the user torelease; and performing the authentication actions as requested andencoded in the multi-dimensional symbol such that the physical identityof the user of the mobile computing device is verified and the userconsents to release the requested identity information at the point ofservice.

Implementations may include one or more of the following features.

The target system may be a mobile computing device of another user or ofa point of sale system. The multi-dimensional symbol may include a QuickResponse (QR) code that uses JSON Web Token (JWT) to encode theauthentication actions. The multi-dimensional symbol may encode anaddress information of the authentication server and an identity tokenfor the user within that server. The multi-dimensional symbol may alsoencodes a key for accessing the authentication server or encoding theauthentication request to be transmitted. The multi-dimensional symbolmay be displayed on the screen of the mobile identity computing deviceof the user. The identity token for the user may be a one-time usetoken.

Accessing the multi-dimensional symbol may include scanning themulti-dimensional symbol using a scanning device at the point of servicesuch that information is retrieved that encodes the user's credentialinformation and a universal resource locator (URL) pointing to anauthentication server.

Accessing the multi-dimensional symbol may include receiving themulti-dimensional symbol using a communication method at a point ofservice such that information is retrieved that encodes the user'scredential information and a universal resource locator (URL) pointingto an authentication server.

Performing the authentication actions may include transmitting a firstrequest to an authentication server at the URL address to have theuser's identity verified based on the credential information. The methodmay further include adding risk-adjusted security level to theauthentication and identity-data requests into the received identitytoken.

The credential information of the user may include a digital identity ofthe user and key information for accessing the authentication server.The user may have pre-registered at the authentication server to havethe credential information of the user verified by third parties atpoints of service in order for the user to receive service at the pointsof service. The credential information of the user may have been vettedby a trusted government entity.

Performing the authentication actions may include executing a requestthrough the authentication server on behalf of the user; receivingverification results from the authentication server that the user'sidentity has been verified; receiving identity data that the userconsented to reply to the authentication request; and executing atransaction on the target system on behalf of the identified user inresponse to receiving the verified identity.

Executing the transaction may include: accessing the user's electronicaccount on behalf of the user. Executing the transaction may includestoring the user's identity information in the target data system.Executing the transaction may include executing on the user's behalf orusing the user's identity information a workflow or transaction in thetarget data system. Executing the transaction may include causing aphysical facility to grant access to the user of the mobile computingdevice. Executing the transaction may be performed on a data server ofthe target system.

Some implementations may include one or more processors and instructionsembedded in a non-transitory machine-readable medium that are executableby the one or more processors. The instructions, when executed, areconfigured to cause the one or more processors to perform the abovedescribed actions. The default position is not to use any externaldatabases, but the system could be configured to perform a databasecheck if needed.

The details of one or more aspects of the subject matter described inthis specification are set forth in the accompanying drawings and thedescription below. Other features, aspects, and advantages of thesubject matter will become apparent from the description, the drawings,and the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a diagram showing an example of securely and privatelyproviding identity information to a target system from a mobile deviceby having the mobile device scanning an external symbol such as a QRcode from a display medium such as a browser page on screen or anydisplay or pre-printed material, the QR code which contains instructionsand endpoints telling the mobile device precisely how to communicate tothe target system.

FIG. 2A is a diagram showing an example of logging in to a target systemviewed through a browser page by having the mobile device scanning anexternal symbol such as a QR code from the browser page and gainingauthorization directly from an authorization server that provides anaccess token which allows access to the target system data server.

FIG. 2B is a diagram showing an example of logging in and providingidentity information to a target system viewed through a browser page byhaving the mobile device scan an external symbol that containsidentifiers to the target system that include directions to verifyspecific identity claims about the consumer using a pre-registeredauthorization server in order to grant access to the target system. Theexternal symbol contains directions on how the authorization servershould forward those claims and the identity directly to the targetsystem, or as in FIG. 2A the mobile device can provide those claims tothe target system.

FIG. 3 is a diagram showing an example of password-less authenticationapproach from a PC browser at a server that authenticates a user forauthorization. The mobile device authenticates the user and releases the“login” transaction on behalf of the browser window for the IdentityProvider to send to the Data Server, instead of the user inputting theirusername and password.

FIG. 4 is a diagram showing an example of token-based authenticationfrom a mobile browser, through an authentication server, at an APIserver.

FIG. 5A is a diagram showing an example of authenticating a consumeruser whose identity is on their mobile device by having a point of sale(POS) device scanning a QR code from the user's mobile device to causethe consumer user's digital identity to be verified at anidentity/authorization server.

FIG. 5B is a diagram showing a variant of 5A an example ofauthenticating a consumer user by having a point of sale (POS) devicescanning a QR code from the user's mobile device to cause the point ofsale device to conduct a transaction through the identity/authorizationserver on behalf of the consumer user, with the consumer being asked toauthenticate and consent to the transaction based on the POS system'srequired security level.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

The age of mobile computing has ushered in endless possibilities ofconnectivity anywhere and anytime. Identity transactions can beperformed through both desktop and mobile computing platforms, such as asmartphone, to engage various data servers, for example, in the cloud.In this context, the sheer volume and complexity of these on-linetransactions may give rise to a digital world fraught with peril,including, for example, identity theft, identity fraud, spoofing,phishing, etc. For these transactions, identity management may become aconsistent theme. As many systems and functionality move to mobiledevices, consumer identity may as well. In that scenario, the mobiledevice carrying a consumer identity will need to field and fulfillidentity requests on behalf of the consumer from all of the devices andsystems used by the consumer or that the consumer interacts with or thatothers with whom the consumer does business interact with.

Some implementations as disclosed herein may provide systems and methodsto power integrated identity management, in which the servers or enginesact in concert with each other to verify the authenticity of anidentity. For example, a symbol, such as a QR code, may be published onthe screen of a browser device, physical world medium such as paper, oranother medium. The published QR code may be scanned by a smartphonedevice. The symbol may contain instructions for the mobile device toestablish or verify an identity at a server that may have issued thesymbol in the first place or at a designated identity or authorizationserver. The mobile device may follow the instructions within the symbolby sending identification credentials in a digital form to anauthentication server, which can return web tokens tailored to themobile device for the application server to utilize. The returned webtoken may provide access control so that the controlling party of theapplication server can prescribe the parties authorized to access theresources of the controlling party as well as the scope of suchauthorized access. For example, the mobile device may send the returnedaccess token, along with a requested resource, to the server, each timethe mobile device requests a restricted resource. The link to therequested resource (such as a universal resource locator) may beincluded in the symbol read by the mobile device. The mobile device maythen follow up the link, for example, by presenting the access token.

Additional implementations disclosed herein provide for the rendering ofa symbol such as a QR code on the display of the mobile device fromwhich a POS or target system can read and then execute the instructionsin order to verify the identity of the user through an identity orauthorization server. Policies at the identity or authorization serveror encoded within the symbol can allow for authentication and consent ofthe user of the mobile identity.

FIG. 1 is a diagram showing an example 100 of accessing a data server106 from a mobile device 110 by having the mobile device opticallyretrieving 114 an external symbol such as a QR code 102 from apre-printed or screen-rendered or communicated via near fieldcommunication on Display Medium 104. The mobile device may then callData Server 106 by using the Instruction 112 to perform a RemoteProcedure Call (RPC) 120. Near-field communication (NFC) is a set ofcommunication protocols that enable two electronic devices, one of whichis usually a portable device such as a smartphone, to establishcommunication by bringing them within about 4 cm (2 in) of each other.Examples of near field communication implementations may includeBluetooth and WiFiDirect with NFC. In the example illustration 100, asymbol is published, for example, at a store front, on the side of avehicle (such as a bus, a train, a taxi), in an electronic communication(such as an email, a text message, a posting at an on-line chat room, orother forms of inter-personal electronic social media communication), ona display medium of the target system that may include a browser window.The symbol may be published by a party hosting data or an API or aworkflow engine on data server 106. In some examples, the symbol caninclude a Quick Response (QR) code 102. In these examples, the symbolmay include a JSON Web Token (JWT) from the JSON Identity Suite thatspecify a link to data server 106 along with instruction 112 and thestandard action for the Data Server to handle. Instruction 112 may alsoembed the symbol for the RPC 120. Instruction 112 may encode Action,Key, and Data specifying parameters and endpoint for performing the RPC120. The Action resulting from the RPC is, for example, to log in, storeinformation, start or continue a workflow on the target system, approvea transaction, start a transaction, etc.

In more details, mobile device 110 may include a smartphone. An examplesmartphone is a mobile phone with an advanced mobile operating systemwhich combines features of a personal computer operating system withother features useful for mobile or handheld use. These smartphonestypically combine the features of a cell phone with those of otherpopular mobile devices, such as personal digital assistant (PDA), mediaplayer and GPS navigation unit, and an image capture device. The imagecapture device may include a camera device, an infra-red imaging device,or other imaging device. The smartphone device may leverage on-boardcamera to optically retrieve (114) the QR code or symbol 102. In otherinstances, the smartphone device may utilize other sensors to take inJWT identity instructions and information in symbolic form 102. In oneinstance, the smartphone device can utilize a near-field communicationto sense the Action, Key, and Data 112 information from a card (muchlike sensing the balance information from a metro card) or otherelectronic device. In another instance, the smartphone device may use aninfrared camera or chroma-shifting algorithm to see such Action, Key,and Data 112 information from a symbol on a physical medium.

Data server 106 may include any computing device with a storage means.In particular, data server 106 may not be limited to a physical computerand may generally include data access points from the cloud.

Display Medium 104 may include preprinted physical media or on-screendisplay media such as on a touchscreen display showing QR code 102within a browser window on the consumer user's mobile device 110.Display medium 104 may also broadcast or otherwise communicate thesymbol.

The use of a full suite of identity instructions and informationincluding a URL inside a symbol such as a QR code 102 in a standardizedformat (e.g., a JSON Identity Suite Web Token (JWT) 102) permitstransmission of an endpoint and parameters from a website (e.g.,referring to data server 106) in the form of, for example, Actions,Keys, and Data into a mobile device (e.g., mobile device 110) so thatthe mobile device can execute a function call in accordance with thespecified Actions and Data. In some implementations, the mobile device110 may utilize a key, as encoded in Instructions 112, to encrypt itsown identity data to follow the Instructions 112 for the RPC 120. In oneinstance, this function call includes a remote procedure call (RPC) toaccess data server 106 at the endpoint or URL inside the symbol 102. Inthis instance, the URL can point to a stationary location. Once the useron mobile device 110 has accessed the URL at the stationary location,the user may be redirected to a location that is more dynamic, forexample, a location that may reflect load balancing needs to serverequests from various regions, or from different time periods orauthorization servers.

Referring to FIG. 2A, a diagram 200 is illustrated in which a user canbe granted access into a target system (such as data server 206) from abrowser 208 displaying the QR code symbol 202. In this illustration,data server 206 renders (201) a symbolic code 202 on the screen of abrowser page 208. Here, the symbolic code 202 encodes instruction 212.Instruction 212 in turn may encode action, key, and data, as discussedabove. As illustrated, such information can be optically retrieved(210), for example, through an optical scanning operation. The retrievedinformation generally provides instructions telling the mobile device204 how to obtain an access token 218 from an authorization server 214so that mobile device 204 is granted authorization (220) to usefunctions or access data as available on the data server 206. Theauthorization server 214 can be a standards-based server, handlingprotocols such as OAuth, User Managed Access, SAML, etc. towardproviding identity or API based authorization on behalf of the dataserver 206 for the identity represented by the mobile device 204.

FIG. 2B is a diagram 230 showing an example of a user being grantedaccess to a target system 206 from a browser page 208 by providing anaccess token 218 to the target system after following instructions 212to verify specific identity claims about the consumer with apre-registered authorization server 214 and instructions to authenticate216 the user themselves before having the authorization sever 214forward the access token 218 directly 220 to the data server 206 therebygaining access to the target system. Similar to the illustration of FIG.2A, data server 206 renders (201) a symbolic code 202 on the screen of abrowser page 208 such that the symbolic code 202 encodes instruction 212that can include Action, Key, and Data. As illustrated, such informationcan be optically retrieved (210), for example, through an opticalscanning operation or retrieved by alternate communications. Theretrieved symbol generally provides instructions for the user of mobiledevice 204 to be authenticated at an authorization server 214 so thatthe user of mobile device 204 obtains authorized access (220) and isredirected to the data server 206 to access resources (such as functionsand data) stored thereon.

In the illustrations for FIGS. 2A and 2B, JSON Identity Suite web token(JWT) can be implemented in the QR code. The general schematic forembedding a JWT in a QR code is such that the JWT represents secureinstructions 212 for the mobile device 204. For example, the secureinstructions can cause the mobile device 204 inquire of an IssuerAuthorization Server (e.g., labeled as ‘iss’) to approve a claim/scope(‘sub’ or ‘prn’) at the requested level of trust (e.g., labeled as‘acr’) and provide the resulting token (e.g., labeled as id_token) orcode (response type ‘typ’) to the relying party's (RP's) specificendpoint (e.g., labeled as ‘aud’) at the data Server. The sender mayalso encrypt the token with a public key (sub_jwk) of the recipient ifsuch information is provided in the instructions 212.

The general schematic discussed above may provide for a comprehensivelist of identity actions that a Relying Party (RP) may request from theissuer so that the identity of a user on a mobile device can beauthenticated by leveraging the authorization server. These identityactions include:

-   -   Login—User uses their identity to log into a service at an RP by        presenting an id_token that the RP has previously        seen/registered;    -   Register—the identity creates a new “account” at a high level of        trust at the RP site with minimal exchange of only required        attributes from the ‘scope’;    -   Associate—the User associates their identity with an existing        “account” at an RP site to which they have already        authenticated;    -   Authenticate—the User proves that they are in still possession        of their identity at the requested level of trust;    -   Consent—the User authenticates and provides consent to the RP's        desired level of trust and their subject consent message;    -   Verify Me—Target System (e.g. POS) calls the User's OP/userinfo        endpoint to obtain the claim the User presented in QR and, once        claim processing starts, User will consent to; and    -   Prove Yourself—User asks their own OP Authorization Server to        prove the scope/claim that the RP wants to know (e.g. ‘over21’).    -   Apply—User exchanges identity information for access to some        benefit or to fill out a form on a web page or a form at the        data server.

Referring to FIG. 3, a sequence diagram 300 shows an example ofpassword-less authentication approach from a PC browser at a server thatauthenticates a user for authorization. The mobile device authenticatesthe user and creates the “login” transaction on behalf of the browserwindow for the Identity Provider to send to the Data Server, instead ofthe user inputting their username and password.

Initially, user 301, at browser window 302, accesses a login page(312A). For example, user 301 may be greeted with an invitation to loginto access an account on-line at browser window 302. The action mayinitiate a request to render the default login page (312B). Here, user301 may not need to provide a username and password combination to begranted access. Instead, the user may be authenticated through arendered default login page that contains, for example, a scannablesymbol.

An initial request to render the default login page may arrive atWeb/Data Server 304. For example, the initial request may be included inthe payload data encapsulated in a POST request during a HTTP (HyperTextTransfer Protocol) session between the login window on the browserwindow 302 and Web/Data Server 304. In response to the request, Web/DataServer 304 may request a scannable symbol (such as a QR code) fromOptical Symbol Rendering Service 306 (314). The Optical Symbol RenderingService 306 may be part of a SaaS (Software as a Service) offered by athird-party identity provider (for example, identity provider 310). Asillustrated, the request may indicate the sought-after scope, level ofassurance, and a Universal Resource Locator (URL) link. The desiredscope may refer to the extent of the access right to be granted to theuser. For example, the amount of data, the type of data, the location ofdata, accessible to the user 301 once the user completes the logintransaction. In some implementations, the desired scope of rights mayeven include the dollar amount being authorized, the type ofuser-submitted transactions, the geographic locations from which theuser may submit transaction requests. The desired level of assurance(LoA) may describe four levels of identity authentication assurancelevels, with Level 1 being the lowest level of assurance and Level 4being the highest level of assurance. Each assurance level describes thedegree of confidence that the user who presented a login credential isin fact that user (i.e., who the presenter purports to be). The URL linkmay refer to the web address of, for example, identity provider 310. Theweb address represents the on-line address where the user's identityclaim is subject to verification, as discussed in further detail below.

In response to the request for the desired scope, level of assurance,and Universal Resource Locator (URL) link, the Optical Symbol RenderingService 306 may create a structure that specifies the desired scope,level of assurance, and Universal Resource Locator (URL) link (316). Insome implementations, the structure is implemented in the form of JSONIdentity Suite Web Token (JWT). Using the formed structure, the OpticalSymbol Rendering Service 306 may then render a symbol, such as QR code(318). Optical Symbol Rendering Service 306 may then return an opticalrepresentation of the symbol to Web/Data Server 304 (320). The opticalrepresentation may refer to data encoding, for example, the created QRcode.

Upon receipt, Web/Data Server 304 may render the created symbol (such asthe QR code) in the Login page (322A). User 301 may visualize the symbol(322B). User 301 may then use a mobile app to scan the symbol beingdisplayed at the Login page (322C) to complete the login transaction. Insome cases, the user can scan the symbol using, for example, an imagecapture device of a mobile computing device of the user such thatinformation from the symbol is optically retrieved. Here, the user 301may be associated with a mobile identity 308, e.g., a digital identityon the user's mobile device (such as a smartphone device). The mobileidentity may be carried around by user 301 and may be protected bysecurity measures to prevent being tampered with. In particular, theuser 301 may have registered mobile identity 308, for example, atidentity provider 310.

To carry out the login transaction, the mobile device of the user mayextract information encoding the scope, the LoA, and the URL from thescanned symbol. Subsequently, the mobile device may send data encodingthe extracted scope and LoA as well as the identity credentialinformation to the URL that corresponds to identity provider 310 (324).The identity credential information may include, for example, a digitalidentity of the user 301. In some implementations, the digital identitymay correspond to a digital identification document that has beenvetted, for example, through a process administered by a governmentagency such as the DMV or the state department.

Upon receipt of the data sent from the mobile device, the identityprovider 310 (often times represented by a server computer) reviews theLoA to determine the desired level of assurance (326A). Depending on thedetermined LoA, the identity provider 310 then leverages the mobileidentity to authenticate the user. In particular, the identity provider310 may rely on the mobile identity (with varying degrees of rigordepending on the LoA) to verify that user 310 is authorized to act withthe scope of requested right to access the account under management ofWeb/Data Server 304 (326B). For example, identity provider 310 mayimplement policies to triage users so that those meet the requisiteconditions (e.g., over 21 to purchase alcohol from an on-line store). Insome implementations, identity provider 310 may interact with mobiledevice to obtain user consent (326E) and then generation an ID token(326D). The ID token may be used to cause the user 310 to login to theuser's account. In some implementations, the ID token may expire after aperiod of time since issuance. In some implementations, the ID token mayencapsulate transactional characteristics that reflect the underlyingtransaction. For example, ID token may indicate the geographic locationfrom which the login attempt is underway. The ID token may betransmitted to an endpoint, such as Web/Data server 304 (328). Based onthe ID token, Web/Data server 304 may verify that user 301 can accessthe account on Web/Data server 304 and with the requested scope ofrights. The determination may be based on the validity and authenticityof the ID token. In response to an affirmative determination, Web/Dataserver 304 may transition to user's account page (332). In some cases,the transition may lead to a new webpage to be displayed that correspondto the user's account page. In other cases, the transition may cause theuser's account page to replace the login page in the browser window. Inany event, the user 301 is now redirected to his/her account page sothat the user 301 can the account page and start a user session at theaccount page.

In these implementations, identity data, purporting to support anidentity claim, can be carried around by mobile device 204. Suchidentity data can be tied to, for example, a smartphone of the user. Theidentity data may be used, along with data retrieved from JWT objectsencoding authentication actions to be taken by the mobile device 204. Inone instance, the mobile device 204 may submit the identity claim at adata server, requesting access, as described in the encodedauthentication actions from the JWT objects. In another instance, themobile device 204 may submit the identity claim at an authenticationserver, which serves as a third-party identity server, for an accesstoken. The mobile device 204 may then use the access token to accessdata at a data server. Thus, the identity data on mobile device 204 maybecome the bridge between the connected world and the mobile device.

FIG. 4 is a diagram showing a diagram 400 of token-based authenticationfrom a mobile browser 402, through an authentication server 404, at anAPI server 406. As illustrated, a browser or mobile client 402 makes arequest 408A to the authentication server 404. Request 408A may be aPOST/auth request that contains user login information such as usernameand password. The authentication server 404 may then generate a new JWTaccess token and encode the access token in a HTTP 200 OK responsemessage 408B. The response message 408B may be returned to mobilebrowser 402. Subsequently, on every request to a restricted resource,the client sends the access token in the query string or authorizationheader. For example, mobile browser 402 may send HTTP/GET dashboardmessage 409A by encoding the earlier received JWT access token. In thisexample, authenticating server 404 then validates the access token and,if it's valid, generates a HTTP/200 OK response message 409B thatincludes the requested secure resource. Authenticating server 404returns the secure resource to mobile browser 402. Thereafter, mobilebrowser 402 may request the secure resource at API server 406.

In this example, the authentication server 404 can sign the access tokenusing a secure signature method. For example, a symmetric key algorithmsuch as Hash-based Message Authentication Code (HMAC) SHA-256 (SecureHash Algorithm-256) can be used if there is a secure channel to sharethe secret key among all parties. In another example, an asymmetric,public-key system, such as RSA, can be used as well, eliminating theneed for further key-sharing.

Token based authentication is stateless. Thus, there may be no need tostore user information in the session. This storage convenience providesthe ability to scale an application without regard to where the user haslogged in. Various login locations can easily use the same token forfetching a secure resource from a domain other than the one the mobilebrowser has already logged in to.

Such authentication also emphasized reusability. In more detail,separate servers may be running on multiple platforms and domains.Reusing the same token for authenticating the user may become desirable.In this context, an application may be built that shares permissionswith another application.

Such authentication may include security. By not using cookies, mobilebrowser 402 and authentication server 404 may not need to protectagainst cross-site request forgery (CSRF) attacks. As long as the accesstokens are encrypted, for example, using tools such as JSON WebEncryption (JWE), sensitive information in an access token may beprotected and such access tokens may be transmitted over, for example,secure hyper-text transport protocol (HTTPS) to preventman-in-the-middle attacks.

Token-based authentication may also improve login performance. In thiscontext, server side lookup may not be needed to find and deserializethe session on each request. The remaining task is simply to calculatethe HMAC SHA-256 tag to validate the token and parse its content.

Referring to FIG. 5A-5B, a diagram 500 illustrates an example of aprocess functioning in the other direction from that of FIG. 1 and FIG.2A-2B. In particular, the example illustrates identifying orauthenticating a consumer user by having a point of sale (POS) devicescanning a QR code on the user's mobile device to cause the consumeruser's digital identity to be verified at an authorization server.

As illustrated in FIG. 5A, the mobile device 502 that is preregisteredwith an authorization server 514 renders (504) a symbol 506 (such as aQR code) that contains information 508 encoding the identity, keys, anda URL to the authorization server (AS) 514. A Point of Sale (PoS) system518 can optically retrieve (510) the symbol 506, for example, by usingan attached scanning device 512 such as an image capture device. The PoSsystem 508 can then utilize the identity, key, and URL pointer toauthorization server (AS) 514 to verify identity or identity claims 516from the mobile device 502. To support an identity or identity claims516, a mobile device 502 can be validated by AS 514 that is chosen bythe mobile device 502 and the PoS system 508 can verify the identityclaim by reading the symbolic code 506 to determine how to verify theidentity data by leveraging information 508 encoding the Identity, Key,and AS 514. One example of such activity is when the QR code contains aJWT that instructs the PoS system 508 on how to verify an age-basedclaim (such as Over-21) about the User of Mobile Device (the targetidentity), as explained above in the supported identity action ofProve-Yourself.

FIG. 5A illustrates an example of authenticating a consumer user byhaving the PoS system 508 scanning a QR code on the user's mobile deviceto cause the consumer user's digital identity to be verified at AS 514.FIG. 5B illustrates another example of authenticating a consumer user byhaving the PoS system 508 scanning a QR code on the user's mobile deviceso that the PoS system 508 can conduct a transaction through AS 514 onbehalf of the consumer user. During pre-registration, user may entrustAS 514 to authenticate the user and consent to be bound by theauthentication results from AS 514. PoS system 508 may submit a requestfor identity or claim 513 to AS 514 who has been entrusted to performthe authentication. PoS system 508 may further receive verified identityor claim 517 from AS 514.

Similarly, a cashier at a check-out stand at PoS may display a QR codecomprising instructions for authenticating the user and authorization atransaction from the user's account. In one illustration, the merchantis preregistered at the authorization server 514. At check-out, whenitems from the shopping cart has been tallied, the cashier may display asymbol, such as a QR code that contains information 508 encoding thestore identity, public key of the store, and a URL to the authorizationserver (AS) 514. The user, when checking out, may optically retrieve(510) the symbol 506 as displayed at check-out stand, for example, byusing an image capture device such as a camera from the user's mobiledevice. The user's mobile device, as a browser device, can then utilizethe store identity, public key, and URL pointer to authorization server(AS) 514 to get in touch with AS 514 to authenticate the user and thenauthorize a transaction. In this example, the QR code contains a JWTthat instructs the mobile device of the user how to authenticate itselfto AS 516 and then authorize a transaction to pay for the items in theshipping cart, as explained above in the supported identity action ofProve-Yourself.

Implementations of utilizing JWT in a QR code are not limited to theabove described use cases. Indeed, various physical check-in mechanismscan incorporate the use of JWT in a QR code. For example, a schoolbuilding may exhibit, at its gate, a QR code with instructions in JWTsuch that when the QR code is scanned by a smartphone device of aregistered student in good standing, the gate may open to grant thestudent access to the school building. The QR code may be displayed onan electronic display and can be updated daily, or as needed. This gatekeeper function can be seen in other cases requiring access control. Forexample, a hotel room may display, on its door, a QR code withinstructions in JWT such that when the QR code is scanned by the guestwho had checked in at front desk and had been assigned to this room, thedoor may open to allow the guest access. Similar use cases can be seenat gym facilities, club houses, apartment complexes, condo entrances,etc.

Various implementations of systems and techniques described here can berealized in digital electronic circuitry, integrated circuitry,specially designed ASICs (application specific integrated circuits),computer hardware, firmware, software, and/or combinations thereof.These various implementations can include implementation in one or morecomputer programs that are executable and/or interpretable on aprogrammable system including at least one programmable processor, whichmay be special or general purpose, coupled to receive data andinstructions from, and to transmit data and instructions to, a storagesystem, at least one input device, and at least one output device.

Computer programs (also known as programs, software, softwareapplications or code) include machine instructions for a programmableprocessor, and can be implemented in a high-level procedural and/orobject-oriented programming language, and/or in assembly/machinelanguage. As used herein, the terms “machine-readable medium”“computer-readable medium” refers to any computer program product,apparatus and/or device (e.g., magnetic discs, optical disks, memory,Programmable Logic Devices (PLDs)) used to provide machine instructionsand/or data to a programmable processor, including a machine-readablemedium that receives machine instructions as a machine-readable signal.The term “machine-readable signal” refers to any signal used to providemachine instructions and/or data to a programmable processor.

Suitable processors for the execution of a program of instructionsinclude, by way of example, both general and special purposemicroprocessors, and the sole processor or one of multiple processors ofany kind of computer. Generally, a processor will receive instructionsand data from a read-only memory or a random access memory or both. Theelements of a computer may include a processor for executinginstructions and one or more memories for storing instructions and data.Generally, a computer will also include, or be operatively coupled tocommunicate with, one or more mass storage devices for storing datafiles; such devices include magnetic disks, such as internal hard disksand removable disks; magneto-optical disks; and optical disks. Storagedevices suitable for tangibly embodying computer program instructionsand data include all forms of non-volatile memory, including by way ofexample semiconductor memory devices, such as EPROM, EEPROM, and flashmemory devices; magnetic disks such as internal hard disks and removabledisks; magneto-optical disks; and CD-ROM and DVD-ROM disks. Theprocessor and the memory can be supplemented by, or incorporated in,ASICs (application-specific integrated circuits).

To provide for interaction with a user, the systems and techniquesdescribed here can be implemented on a computer having a display device(e.g., a CRT (cathode ray tube), LCD (liquid crystal display) monitor,LED (light-emitting diode) or OLED (organic light-emitting diode)monitors) for displaying information to the user and a keyboard and apointing device (e.g., a mouse or a trackball) by which the user canprovide input to the computer. Other kinds of devices can be used toprovide for interaction with a user as well; for example, feedbackprovided to the user can be any form of sensory feedback (e.g., visualfeedback, auditory feedback, or tactile feedback); and input from theuser can be received in any form, including acoustic, speech, or tactileinput.

The systems and techniques described here can be implemented in acomputing system that includes a back end component (e.g., as a dataserver), or that includes a middleware component (e.g., an applicationserver), or that includes a front end component (e.g., a client computerhaving a graphical user interface or a Web browser through which a usercan interact with an implementation of the systems and techniquesdescribed here), or any combination of such back end, middleware, orfront end components. The components of the system can be interconnectedby any form or medium of digital data communication (e.g., acommunication network). Examples of communication networks include alocal area network (“LAN”), a wide area network (“WAN”), and theInternet.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

A number of implementations have been described. Nevertheless, it willbe understood that various modifications may be made without departingfrom the spirit and scope of the invention. For example, much of thisdocument has been described with respect to messaging and mappingapplications, but other forms of graphical applications may also beaddressed, such as interactive program guides, web page navigation andzooming, and other such applications.

In addition, the logic flows depicted in the figures do not require theparticular order shown, or sequential order, to achieve desirableresults. In addition, other steps may be provided, or steps may beeliminated, from the described flows, and other components may be addedto, or removed from, the described systems. Accordingly, otherembodiments are within the scope of the following claims.

What is claimed is:
 1. A method to have a user authenticated at a pointof service and to release identity information, the method comprising:accessing, by a target system, a multi-dimensional symbol rendered on adisplay of a mobile computing device of the user, the multi-dimensionalsymbol encoding endpoints and actions for the target system to performin order to request and authenticate an identity of a user; decodingdata in the multi-dimensional symbol to retrieve an identity token plusinformation about the authentication actions and the user's identitysystem; requesting the corresponding authentication actions of theuser's identity system to include specific authentication measures forthe user to perform as well as data for the user to release; andperforming the authentication actions as requested and encoded in themulti-dimensional symbol such that the physical identity of the user ofthe mobile computing device is verified and the user consents to releasethe requested identity information at the point of service.
 2. Themethod of claim 1, wherein the target system is a mobile computingdevice of another user or of a point of sale system.
 3. The method ofclaim 1, wherein the multi-dimensional symbol includes a Quick Response(QR) code that uses JSON Web Token (JWT) to encode the authenticationactions.
 4. The method of claim 1, wherein the multi-dimensional symbolencodes an address information of the authentication server and anidentity token for the user within that server.
 5. The method of claim1, wherein the multi-dimensional symbol also encodes a key for accessingthe authentication server or encoding the authentication request to betransmitted.
 6. The method of claim 1, wherein the multi-dimensionalsymbol is displayed on the screen of the mobile identity computingdevice of the user.
 7. The method of claim 4, wherein the identity tokenfor the user is a one-time use token.
 8. The method of claim 1, whereinaccessing the multi-dimensional symbol comprises: scanning themulti-dimensional symbol using a scanning device at the point of servicesuch that information is retrieved that encodes the user's credentialinformation and a universal resource locator (URL) pointing to anauthentication server.
 9. The method of claim 1, wherein accessing themulti-dimensional symbol comprises: receiving the multi-dimensionalsymbol using a communication method at a point of service such thatinformation is retrieved that encodes the user's credential informationand a universal resource locator (URL) pointing to an authenticationserver.
 10. The method of claim 8, wherein performing the authenticationactions comprises: transmitting a first request to an authenticationserver at the URL address to have the user's identity verified based onthe credential information.
 11. The method of claim 10, furthercomprising: adding risk-adjusted security level to the authenticationand identity-data requests into the received identity token
 12. Themethod of claim 4, wherein the credential information of the userincludes a digital identity of the user and key information foraccessing the authentication server.
 13. The method of claim 12, whereinthe user has pre-registered at the authentication server to have thecredential information of the user verified by third parties at pointsof service in order for the user to receive service at the points ofservice.
 14. The method of claim 12, wherein the credential informationof the user has been vetted by a trusted government entity.
 15. Themethod of claim 1, wherein performing the authentication actionscomprises: executing a request through the authentication server onbehalf of the user. receiving verification results from theauthentication server that the user's identity has been verified;receiving identity data that the user consented to reply to theauthentication request; and executing a transaction on the target systemon behalf of the identified user in response to receiving the verifiedidentity.
 16. The method of claim 15, wherein executing the transactioncomprises: accessing the user's electronic account on behalf of theuser.
 17. The method of claim 15, wherein executing the transactioncomprises: storing the user's identity information in the target datasystem.
 18. The method of claim 15, wherein executing the transactioncomprises: executing on the user's behalf or using the user's identityinformation a workflow or transaction in the target data system.
 19. Themethod of claim 15, wherein executing the transaction comprises: causinga physical facility to grant access to the user of the mobile computingdevice.
 20. The method of claim 15, wherein executing the transaction isperformed on a data server of the target system.